A denial-of-service attack (DoS attack) is an unauthorized attempt to make a computer resource unavailable to its intended users. DoS attacks are intended to prevent a network service from functioning, either on a temporary or a permanent basis. There are different ways in which DoS attacks can be performed. A simple DoS attack against a server is to flood it with sufficient random traffic that the links used by the server get too congested for legitimate traffic to pass through, thereby denying the services of the server to legitimate users. Such an attack may render the server unable to handle legitimate traffic altogether, or may render the server's handling of legitimate traffic so slow as to be effectively unusable.
A more elaborate DoS attack can be performed by sending to the server service requests that appear to be legitimate, but may contain forged authentication data. When the server receives a service request, it allocates resources for the request. The number of legitimate service requests required to render a server ineffective is typically much lower than simply flooding the links to the server, as the requests require more server resources to handle.
Problems with preventing or limiting DoS attacks will now be described with reference to the Generic Bootstrapping Architecture (GBA). However, it will be appreciated that these problems can occur in other network architectures.
Referring to FIG. 1, when a User Equipment (UE) 1 wishes to be authenticated in a network, it is mutually authenticated with a Bootstrapping Server Function (BSF) 2 using the Authentication and Key Agreement (AKA) protocol. This authentication takes place over a Ub reference point. The result of the AKA run is a shared secret between the UE 1 and the BSF 2 in the form of a key, Ks. As part of the procedure, the BSF 2 also sends an identifier for the Ks, termed a B-TID, to the UE 1.
When the UE 1 subsequently wishes to use a service provided by a Network Application Function (NAF) 3, it contacts the NAF 3 and sends the B-TID to the NAF 3. The NAF 3 contacts the BSF 2 using a secure channel, and requests NAF-UE specific keys from the BSF 2 to authenticate the UE 1 and protect the communication with the UE 1. As the UE 1 has previously bootstrapped with the BSF 2, the BSF 2 returns a key (Ks_NAF) to the NAF 3. Ks_NAF is derived from Ks, a NAF identifier and some other parameters. All of these parameters are available to the UE 1, so the UE 1 can derive Ks_NAF locally. The NAF 3 and the UE 1 both have knowledge of Ks_NAF, and this can be used to secure communication between the UE 1 and the NAF 3.
One way to circumvent the problem of a DoS that consists of too many legitimate requests is to apply a rate limit on the number of requests received from a certain unit or network segment such as a UE 1. In addition to this it is customary to design the protocols so that the NAF 3 allocates as few resources as possible to a request until it is certain about the identity of the client, and that the request is not part of a DoS attack.
In GBA, the NAF 3 verifies the identity of the UE 1 by requesting the key the UE 1 is expected to use from the BSF 2, and then this key can be used to authenticate the UE 1. A problem with this approach is that if one or more UEs use a random spoofed B-TID and their source addresses, the NAF 3 has to ask the BSF 2 for the corresponding UE-NAF keys, and get a (negative) response, before it can deduce that the request was not legitimate. In addition to this, since the requests are unlikely to use the same source address or B-TID more than once, there is no information that the NAF 3 can use to quickly detect that the requests are bogus. This therefore places a large processing burden on the NAF 3 in formulating requests to the BSF 2, and a large burden on the network in transporting the requests and responses between the NAF 2 and the BSF 3.
Other mechanisms for preventing flooding of a server with legitimate requests are based on a server providing the requesting client with a puzzle to solve before the actual communication begins. Solving the puzzle places a processing burden on the requesting client, which limits its ability to send a large number of requests. A drawback with this approach is that it delays the start of the communication, and that extra roundtrips are required from the protocols. There is therefore a need to authenticate a requesting client with a server that reduces the signalling required between the server and a BSF, and reduces delays in authentication.